home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Arsenal Files 1
/
The Arsenal Files (Arsenal Computer).ISO
/
bbs
/
tm0305.txt
< prev
next >
Wrap
Text File
|
1994-01-23
|
31KB
|
610 lines
SEA Technical Memorandum #0305, Adding GroupMail to a Bink/Confmail System
Contributed by: Jack Decker
Last updated: March 7, 1989
Copyright 1989 by System Enhancement Associates, Inc.
Adding GroupMail to a Binkleyterm/Confmail System
This document is an attempt to give you some solid information on how to
implement GroupMail on a system that is already successfully running
BinkleyTerm and confmail.
This information is going to be presented more or less in "cookbook"
format. I am going to make a few assumptions to start with... that you are
not a "top star" for any conference, that you're not going to feed
GroupMail conferences to any non-MSDOS systems that can't run the GroupMail
software, and that you're not going to try and convert any GroupMail
conference to Echomail or vise-versa. If any of these assumptions don't
apply to you, read on anyway, I'll cover one of the exceptions later, and
the rest of the information will still be useful to you.
This is NOT a substitute for the GroupMail documentation. Read it, too!
Also, please count on this information containing at least one glaring
error and at least a couple of things that could have been done more easily
in some other way. I don't claim to be perfect. But I would like to know
of any errors that you do find.
Here are the changes you will need to make to your system:
1) CONFIG.SYS - Group requires some new environment variables to be set.
If you haven't already done so, you can reserve extra space for
environment variables by inserting the following line into your
CONFIG.SYS file:
shell=command.com /p /e:512
2) AUTOEXEC.BAT - Here is where you add a new line to set a new
environment variable that will be used by GroupMail:
SET SEADOG=C:\OPUS
The SEADOG variable should point to the directory that you normally run
BinkleyTerm from.
3) BBS.BAT - Your batch file that runs Binkley, ConfMail, etc. Here are
the changes you need to make:
a) If you test for the existence of mail bundles in your net files area
before running ConfMail Import, either delete these tests (you don't
really need them anyway) or add tests for the GroupMail bundles you
expect to receive. GroupMail bundles are named with the area name
(up to eight characters) plus an unpredictable three-character
extension. So, for example, if you are expecting to receive
GroupMail bundles for the COOKING area, you could test for files
named COOKING.* (or COOKING.???) in your net files area. I again
emphasize that such tests are normally not necessary, but some
people like to use them to shave a few seconds off of batch file
processing time.
b) your line that calls ConfMail Import should *NOT* include the -M
option, but *SHOULD* include the -K option. I use the following
line:
confmail import areas.bbs -K -N -F confmail.out
Now a bit of explanation... if you really want to use the -M option,
you can probably do so as long as you are not converting any
GroupMail bundles to echomail prior to passing them downstream. I
suggest removing the -M option now (if you have been using it)
because sooner or later you may wish to convert a GroupMail
conference to echomail, and it won't work if -M is set.
The -K option will automatically kill all the null file attach
messages that your GroupMail feed generates. If you don't mind
skipping through all the null file attach messages when you read
your netmail (you WILL mind eventually), leave out the -K.
c) You should place the following line immediately AFTER your call to
ConfMail Import, BEFORE you do anything else:
GROUP IN /L
This does two things... first, it unpacks any GroupMail bundles you
may have received, and second, it scans your netmail area for any
GroupMail messages that need to be readdressed to your uplink. That
is why it needs to be run AFTER ConfMail Import... if you run it
BEFORE ConfMail Import, any messages you've received from your
downstream nodes may not get properly forwarded to the Top Star via
your GroupMail feeds. And you need to run Group In BEFORE running
ReMapper, oMMM, or any other program that may change the headers of
those messages. So play it safe, and run Group In right AFTER
ConfMail Import.
By the way, the /L tells GROUP to relink the message threads. It
does basically the same thing for GroupMail conferences that
ReplyLnk (or ConfMail Maint in older versions of ConfMail) does for
your echomail conferences.
d) Just prior to calling oMMM, you should place the following line:
GROUP OUT
This will check all your GroupMail areas for new messages, and send
out anything you have waiting.
Now, if you have read the GroupMail documentation, you may be a little
confused at this point, since the docs tell you to run GROUP on certain
schedules (GROUP OUT in the evening before your mail hours, and GROUP
IN in the morning after all mail has been received). But keep in mind
that the folks writing the documentation are using SEADOG, which runs
on schedules. You probably aren't running schedules in that way. If
by chance you do run ConfMail Import only at certain specified times,
just do GROUP IN immediately afterward. But, if like most of us, you
run ConfMail Import every time mail is received, you should run GROUP
IN immediately afterward. If you then do a ConfMail Export, you should
run GROUP OUT prior to calling oMMM. GROUP runs very fast (faster than
ConfMail when tossing messages, in my opinion) so you needn't worry
about it consuming an inordinate amount of time while executing on your
system.
4) AREAS.BBS - There are two important considerations here. First, if you
are using a BAD_MSGS area, GET RID OF IT NOW!!!! This is *EXTREMELY*
important. If you don't do this, some or all of the GroupMail messages
originating on your system (or on systems that you feed) will be tossed
to the BAD_MSGS area by ConfMail, and will never leave your system.
Second, make sure you don't have any echo area names that duplicate
GroupMail areas, for the same reason (ConfMail will toss any messages
that are supposed to go to your uplinks to those areas instead. The
exception to this is if you're converting a GroupMail conference to
Echomail, but right now we're assuming you aren't doing that,
remember?).
Of course, someone will say that if you are VERY careful about how you
write your batch file, you can get around these problems. That may be
true (although I have my doubts!), but in any event I don't feel like
giving a short course in writing batch files here. I'm simply taking
the safe road by saying "don't do these things."
5) CONFIG.DOG - You need one of these, even though the GroupMail
documentation says that a Mail.Sys file will do (it won't, at least not
with GroupMail versions through 2.04). Fortunately, a Config.Dog file
is simple to make... you just use any text editor. Mine looks like
this:
name Jack Decker
node 1:154/8
aka 77:1011/8
aka 8:70/8
mail C:\MSG\NET
files C:\FILE\NET
"Name" is the name of the Sysop, "Node" is your primary address, "Aka"
lines contain any other addresses you use (in the same net or in other
nets), "Mail" is the path to your netmail area, and "Files" is the path
to your incoming net files area (which is what GROUP can't find if you
only have a Mail.Sys file).
6) OMMM.CTL (or ROUTE.CTL or whatever you call it on your system). Be
sure to put a poll statement in for each system you pick up GroupMail
from (unless you are using some other method for doing polls, or your
feed is calling you).
7) DELIVER.GRP - You need this file if you are feeding GroupMail to any
other BinkleyTerm systems, or any other system that can't generate File
Update Requests. Note that future versions of BinkleyTerm will
supposedly include the capability to do File Update Requests, but
present versions of Binkley do not. DELIVER.GRP is simply a list of
systems that are to receive any given GroupMail area from you. I quote
from SEA Technical Memorandum #0302:
"The GroupMail conferencing system is, by design, a pickup system
instead of a delivery system. If at all possible, it should be used as
such, because that is how GroupMail avoids the bulk of the technical
problems with echomail.
"However, at least one popular network mailer is not capable of
properly negotiating a file update request, which is the mechanism by
which GroupMail functions. Until that can be rectified, GROUP requires
some sort of delivery mechanism in order to link such systems into
GroupMail.
"If a file named 'DELIVER.GRP' is placed in the SEAdog directory, then
GROUP 2.03 will use it as a delivery list, and create file attach
messages for each new GroupMail archive as it is posted by GROUP PACK
(for a top star) or GROUP IN (by a middle star). The format of the
DELIVER.GRP file will look very familiar to those acquainted with
echomail.
"The DELIVER.GRP file is a normal ASCII text file. Each line begins
with the name of a group conference, with the remainder of the line
being a list of network addresses to which it should be delivered. A
conference may be listed more than once, in which case it is addative.
"For example, a possible DELIVER.GRP file might be:
BLATZ 520/1015 107/528
GNORF 107/528
"By adding support of a delivery mechanism, we open the door to all the
troubles echomail is heir to. However, the door is open only a tiny
crack at this time. The single biggest problem with a delivery system
is that of faulty topologies that cause duplicate messages. This is
largely avoided from the start because all duplicate GroupMail archives
have the same name. The remaining opportunities for duplicate messages
to be generated are avoided because GROUP 2.03 refrains from unpacking
any GroupMail archive that is older than the 'update marker' for that
conference."
[end quote]
Two notes about DELIVER.GRP... first, you DON'T put the node number of
YOUR feed in it, only of those systems that are fed BY YOU (this
differs from an AREAS.BBS file, which must contain the node number of
your feed and of those system that you feed). Second, if you aren't
feeding a particular GroupMail conference to anyone else, it doesn't
have to be listed at all.
8) OKFILE.LST - Your "requestable files" list for BinkleyTerm. Add the
following line:
C:\GRPHOLD\*.*
(or whatever path you specified for your GRPHOLD directory in the SET
command in AUTOEXEC.BAT). I'm assuming that you already have such a
list. If not, you'll also need to uncomment the following line in your
Binkley.Cfg file:
Okfile c:\opus\okfile.lst
(of course you should change the path if the subdirectory you're
running Binkley out of is not called OPUS).
This should allow other systems to obtain any GroupMail areas that you
carry on your system.
9) \GROUP\ORIGIN - A file called "Origin" that sits in your GROUP
directory. For starters, this can be the same as the first line of
your "AREAS.BBS" file up to the exclamation point. You can use custom
origin lines for individual conferences by creating a file called
"Origin" in individual Group areas, in the same manner in which you
create custom origin lines for individual message areas using ConfMail.
See the GroupMail documentation for more information.
10) System files. You'll need to provide your BBS program and/or message
reader/editor with the paths to your GroupMail areas. Ditto with your
message cleanup routine (that calls RENUM or some other message
renumberer). This will vary from system to system, but should not be
too difficult to figure out.
11) GROUP.EXE - The central program of GroupMail, and the one that does
most of the work for you. If you've set up echomail conferences in the
past, you'll appreciate the ease with which GROUP takes care of many of
the little details of adding or deleting conferences for you. For
example, it creates all necessary subdirectories for you, creates and
maintains the AREAS.DOG file for you, etc.
Now, if you are not a Top Star, you can basically get by using only three
basic GroupMail commands (quoted from the GroupMail documentation):
GROUP ADD <conference> <description> ;<uplink>
This is the command you use to add a new conference. Suppose, for
example, that you would like to get the BLATZ conference from 520/542.
You would type:
GROUP ADD BLATZ Gzorniblatz forum ;520/542
GROUP will take care of the details, like creating the proper
directories and updating your AREAS.DOG file. If you run a BBS and
you want the conference to be available on your system you will need
to add the directory to your message areas. The message directory
that GROUP creates will (by default, see later) be a subdirectory of
the GROUP subdirectory, or in this case it would be "GROUP\BLATZ".
If you are running a mailer other than SEAdog, then you may need to
add the directory to your areas list also. In any event, DO NOT
delete the AREAS.DOG file, as that is used by GROUP to keep track of
your conferences.
If you want to import GroupMail into a BBS that uses a different
message base format, you'll need to do a bit more work. See the
section on this below.
[You might imply from the above that you should add GroupMail areas to your
AREAS.BBS file. That is NOT the case, however, unless you are converting a
GroupMail conference to echomail, which we're assuming that you're not
doing right now!]
GROUP DEL <conference> . . .
This is used to remove one or more conferences. For example, if you
wanted to remove the BLATZ conference you would type:
GROUP DEL BLATZ
If you wanted to remove both the BLATZ conference and the GNORF
conference, you would type:
GROUP DEL BLATZ GNORF
Again, GROUP will take care of the housekeeping details, such as
deleting any messages and removing the subdirectory.
GROUP EDIT <conference> <description> ;<uplink>
This is used to change an existing conference. For example, if you
wanted to change your uplink on the BLATZ conference to 440/1, you
would type:
GROUP EDIT BLATZ Gzorniblatz forum ;440/1
As always, GROUP takes care of any housekeeping details.
[end of quoted material]
Since Binkley can't do File Update Requests, you do NOT use the GROUP ASK
command. We've already covered the use of GROUP IN and GROUP OUT in the
batch file. You don't use GROUP PACK unless you're a top star for a
conference.
There are several option switches that you can use to modify how GROUP
works, and most are described in the GROUP documentation. The one that you
will probably want to use is the /R switch:
/R<x> Retention; This tells GROUP that any GroupMail archives that you
are holding (if you are a star) should be deleted after <x> days
(default is 30 days). For example, you would use "/R5" to retain
archives for five days.
For example, if you wanted to add the BLATZ conference with yourself as a
middle star retaining GroupMail archives for three days, you would type:
GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /r3
Also, because Binkley cannot generate File Update Requests, you'll want to
use the /X switch when adding new conferences, as described in SEA
Technical Memorandum #0302:
/X In ADD or EDIT only. This switch indicates that the designated
conference should not be requested. The GROUP ASK command will not
generate an update request for any conference that carries this
switch. This is intended mainly for use with conferences which are
delivered or which are obtained via a GROUP GET (see above).
The bottom line is that when you add a new GroupMail conference, your GROUP
ADD line will most likely appear something like this:
GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /X /r7
(assuming you want to retain conference archives for seven days in this
case).
If you are a leaf node (that is, you don't hold a particular conference for
anyone else to pick up), omit the asterisk and the /r7 in the above line.
In this case, the GroupMail bundle will be deleted after it has been
tossed. The command line would then look like this:
GROUP ADD BLATZ Gzorniblatz forum ;520/542 /X
When you use the GROUP EDIT command, it should be in exactly the same
format as the GROUP ADD command. In other words, if you are adding
switches, you must also re-enter all of the original switches. The word
EDIT simply tells Group that you are modifying the particulars of an
existing conference, rather than creating a new one.
EXCEPTIONS AND SPECIAL CIRCUMSTANCES
The GroupMail manual tells you how to import GroupMail into non-compatible
message base formats (such as QuickBBS or TBBS). In this case you use the
/N flag in your GROUP ADD statement. Since most such systems don't use
ConfMail, this type of setup is a bit beyond our discussion. I would only
caution you to be careful about the sequence in which you run you mail
import routine and GROUP IN. You may have to run your import routine
twice... once to toss incoming mail, then GROUP IN to toss incoming
GroupMail bundles to the netmail area (and to readdress any GroupMail
messages destined for your uplinks), and once more to import any GroupMail
messages tossed to your netmail area by GROUP. This is just guessing on my
part, since I don't have any actual experience with such systems.
However, a similar technique is used to convert GroupMail to Echomail. You
might want to do this if you are receiving a GroupMail conference and want
to pass it on to another system that cannot run the GroupMail software.
Now, I would suggest that you DON'T do this unless absolutely necessary.
If it's just a case of one of the nodes you feed objecting to having to put
up the GroupMail software (although they are perfectly capable of doing
so), I would invite them to seek a feed elsewhere. Converting a conference
from GroupMail to Echomail introduces several possible headaches, not the
least of which is that you could be the source of duplicate messages
entering the conference.
On the other hand, it's not something that's terribly difficult to do if
you have to. SEA Technical Memorandum #0303 describes the process, but I
will give a couple of examples specifically for BinkleyTerm/ConfMail users.
The assumption here is that you are a middle star that is receiving the
conference in question as GroupMail, and feeding it to some other nodes as
GroupMail while feeding still other nodes as Echomail.
Your GROUP ADD line would be the same as usual, with the addition of the /N
switch. For example:
GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /N /X /r7
If you are not sending the conference to any other nodes AS GROUPMAIL, you
can omit the asterisk and the "/r7" switch.
Next, you ADD this area to your AREAS.BBS file, just like you would any
normal echo. On your system, you will treat this conference as an echomail
area rather than a GroupMail area. The /N option that you used in your
GROUP ADD statement causes GROUP to add an "AREA:" field and a "SEEN-BY:"
field listing the address of the uplink to any conference that you're
converting to echomail.
In your batch file, you will probably want to run ConfMail Import (WITH the
-M option), THEN Group In, and THEN a second run of ConfMail Import
(WITHOUT the -M option). This will make sure that any GroupMail received
from your downstream nodes gets properly readdressed to your uplinks, and
that any Group conferences that GroupMail tosses to your netmail area get
properly tossed (by ConfMail) to the Echomail area you've set up for that
conference. For example:
confmail import areas.bbs -M -N -F confmail.out
group in /L
confmail import areas.bbs -K -N -F confmail.out
The only other items you have to worry about are how the area is defined in
your DELIVER.GRP and AREAS.BBS files. As usual, your DELIVER.GRP file
should contain ONLY a list of nodes receiving the conference from you AS
GROUPMAIL. Your AREAS.BBS entry for the conference in question should
contain a list of the nodes receiving the conference from you AS ECHOMAIL,
plus YOUR FEED of the conference. The reason for including your feed is so
that any messages entered on your system, or sent to you by your downstream
links, will be exported to your upstream feed.
You may wonder what will happen to an echomail message sent upstream in
such a manner to your GroupMail feed. If he is running that area strictly
as GroupMail, the message will be tossed into his netmail area (so long as
he does not have a BAD_MSGS area... this is why you CANNOT use a BAD_MSGS
area with GroupMail!!!), where (hopefully) GROUP IN will find it and
readdress it to his uplink, and so on. If he is also operating the area as
both echomail and GroupMail, the message will get tossed into the echo area
on his system, and then exported to his upstream feed, and so on.
Anyway, that's all there is to it... BUT again I ask, "do you REALLY want
to convert echomail to GroupMail?" If you are only feeding one or two
nodes that cannot accept GroupMail, there may be a better way:
SENDING GROUPMAIL TO NON-MSDOS SYSTEMS
The following information should be considered HIGHLY experimental. If it
works for you, GREAT! If it doesn't, well, you can always convert your
GroupMail conferences to echomail.
Let's say that you're feeding a point system that's running on a Commodore
Amiga (coincidentally, this is what Steve Palm, a point operator off of my
system is using). He has a version of ConfMail and BinkleyTerm that's been
ported to the Amiga, as well as a message reader/editor, but there is no
way he can run the GroupMail software.
But, he is a leaf node. That means he doesn't have to worry about
forwarding the conference to anyone else. All he needs to be able to do is
to read the messages he receives, and send replies.
We already know (from the above discussion) that if he creates an echo area
with the same name as a GroupMail area on my system, and puts my node in
his AREAS.BBS list, that any messages he enters in that area will be
exported to my system, where GROUP IN will find them and readdress them to
my feed for the conference. So as long as he can send me messages with the
proper AREA tag (which will be automatically affixed when ConfMail exports
the message from the echo area he's created), he will be able to enter
messages in a GroupMail conference. So, if he can figure out some way to
process an incoming GroupMail bundle (so that he can read incoming
messages), I can just put his node in my DELIVER.GRP file and treat him
like any other GroupMail delivery point (which means I don't HAVE to
convert the GroupMail conference to Echomail!)
The question is, can he unpack a GroupMail bundle? Well, it turns out that
there IS a way this can be done. Once you extract a GroupMail packet from
its archive, the extracted mail packet has roughly the same format as an
Echomail packet, except that it's addressed to -1/0. At least, it's close
enough that ConfMail will unpack and toss it if it thinks it's running on
node -1/0
So, in his CONFIG.DOG file, Steve inserts the address -1/0 as an AKA
address. Then, in his batch file, he has to put a command to look for and
unARC any GroupMail bundles he might receive. For example, if he's getting
COOKING and SHORTWAV from me, he'd put in the following lines (note these
are MS-DOS batch file lines for illustrative purposes only, not what Steve
is actually using on his Amiga):
ARCE \FILE\NET\COOKING.*
DEL \FILE\NET\COOKING.*
ARCE \FILE\NET\SHORTWAV.*
DEL \FILE\NET\SHORTWAV.*
CONFMAIL IMPORT AREAS.BBS -N -A ARCE
ConfMail will find the bundles (addressed to -1/0, but the AKA takes care
of that) and unpack them. Next... and this is important... he must do a
CONFMAIL EXPORT using an alternate AREAS.BBS format file that contains the
following:
Origin Line ! Sysop Name
\MSG\COOKING COOKING -1/0
\MSG\SHORTWAV SHORTWAV -1/0
Why are we exporting to -1/0? Well, since GroupMail uses that address, I
thought I would, too... actually, we could export to ANY phony node, but
the idea is to make ConfMail do an export operation on the newly-imported
GroupMail messages. Why? Well, keep in mind that GroupMail messages don't
have an origin or SEEN-BY lines. Thus, if we simply allow them to be
rescanned in the normal manner, we've created an instant dupe loop, since
they will all get sent back to the source. So, we do a "dummy" export
operation in order to reset the "high water mark" past the last new message
that we have just received in the area. This may create an unwanted ".OUT"
file for -1/0, but we can always delete that as the next operation in the
batch file
So, the complete batch file segment would look something like this:
ARCE \FILE\NET\COOKING.*
DEL \FILE\NET\COOKING.*
ARCE \FILE\NET\SHORTWAV.*
DEL \FILE\NET\SHORTWAV.*
CONFMAIL IMPORT AREAS.BBS -N -A ARCE
CONFMAIL EXPORT ALTAREAS.BBS {options}
DEL \OUTBOUND\FFFF0000.OUT
where ALTAREAS.BBS is the alternate AREAS.BBS with the dummy -1/0 net/node
numbers, and FFFF0000.OUT is the name of the mail packet (for -1/0) created
by the dummy export operation.
Of course, when messages are entered using the message reader/editor, we
have to run ConfMail Export using the "real" AREAS.BBS file that contains
the same entries, but with the real net/node numbers for the GroupMail
feed(s) from which the conferences are received:
Origin Line ! Sysop Name
\MSG\COOKING COOKING 154/8
\MSG\SHORTWAV SHORTWAV 154/8
Now, all of the above will work BUT there is one MAJOR problem. It turns
out that while each GroupMail bundle has a unique filename, two or more
GroupMail bundles for the same conference can contain .PKT files that have
exactly the SAME names. Thus, there is a very good chance that the above
batch file segment would fail whenever more than one mail bundle is
received for the SAME GroupMail area in the same transmission (it would
most likely stop and ask the user whether to overwrite the the .PKT file
from the first mail bundle with the .PKT file from the second... or on some
systems, it might just go ahead and overwrite the file without asking, an
even less desirable situation!). On an MSDOS machine, you could use a FOR-
DO loop in the batch file to unarc each GroupMail bundle and then have
ConfMail toss (import) the contents of that mail bundle before unarcing and
tossing the next GroupMail bundle (but then, on an MSDOS machine you could
just run the GroupMail software). There are probably ways to accomplish
the same thing on other systems, but the actual method would depend on the
commands available in the batch file language, and/or the availability of
external utilities that might aid in the process. Or, you could just run
the batch file manually (when an operator is present to watch and resolve
any such conflicts that might occur)... that might be the most expiditious
method at present for point system operators. Note to the developers of
GroupMail: It would sure be nice if future versions did not create
duplicate .PKT names within different mail bundles for the same GroupMail
conference.
The method I've shown for preventing the imported GroupMail messages from
being rescanned back to the GroupMail feed is not real elegant, and begs
for a simple utility that would either a) reset the "high water mark" (the
number of the last message scanned by ConfMail Export) to that of the
highest message in the area, or b) append an Origin line and SEEN-BY lines
to any messages that don't already have them in the specified area, and
place the net/node number of the feed for the area in all messages
currently in that area. Such a utility could be run every time messages
have been tossed to the specified area, and would eliminate the need for
the dummy ConfMail Export operation. Yet another (better) option would be
to forget the alternate AREAS.BBS file and the dummy ConfMail Export
option, but instead use only the regular AREAS.BBS file with NO net/node
number following the Group conference area names, so that messages in Group
areas would NEVER be exported by ConfMail. Then use a separate utility
that would search through Group conference areas for locally-originated
messages (messages containing the node's primary net/node number in the
FROM field of the message header) and move those TO the netmail area, at
the same time readdressing them to the feed for the GroupMail conference
and flagging them as Kill/Sent. Such a utility would be relatively easy to
create, and would allow non-MSDOS systems to handle GroupMail in a way that
more closely resembles the way GroupMail is supposed to operate (that is, a
locally-entered message disappears from your BBS until such time as it
comes back as part of a GroupMail packet).
But, at this point, the fact that a non-MSDOS system can import and process
GroupMail is a bit akin to the dancing bear... the wonder is not how well
it's done, but that it can be done at all.
I hope that these hints prove helpful to you in setting up GroupMail on
BinkleyTerm/ConfMail and other types of systems. Please let me know if you
find any glaring errors in the above information, or if you can add
anything that might simplify the process or make it more understandable.